fix(agents): Record whose work a child agent does in its session log - #2181

Refs #2439

This adds the plan for #2439 in
`openspec/changes/actor-identity-end-state/`. It also adds **Owner** and
**Trusted author** to `TERMINOLOGY.md`, and says that an Automation has
a creator, not an owner (also in the dashboard Automation editor
README). There is no code change.

The plan fixes the target and the rules. It does not fix the
implementation. At the start of each step, the step re-checks the plan
against current `main` and settles its own details (SQL, keys, field
names, signatures, readers, tests) in its PR. A change to a decided rule
needs David's OK.

- `proposal.md`: scope, David's answers, plan decisions, open questions,
behavior changes, and risks.
- `design.md`: the model and rules, the current proposals that a step
must confirm, and the known gaps.
- `tasks.md`: how to use the plan, release rules, dependencies, and
steps 1–7. Each step has a goal, a done outcome, constraints, and what
to decide in that step.
- `specs/conversation-identity/spec.md`: the end-state requirements and
scenarios.

**Decided by David Cramer in the Slack thread**

- The Owner is the person who started the Conversation, or the system
for an automation. Owners never transfer.
- There should be no unknown actors on any Message from now on.
- The local CLI user can be the system Identity.
- A web user is the User they sign in with, through the normal User and
Identity tables.
- The schema should be normalized.
- Assistant output is just an event. It needs no author Identity.
- Web users always have an Identity. The mock viewer mocks one.
- Child spend rolls up to the root Owner.
- Slack bots have an Identity but no User.
- For an inbound event, Junior finds the correct Identity and verifies
it the same way as everywhere else. Junior ignores the instructions of
someone without access.
- Most events are system events, with the system Identity as author. PR
feedback and comments are authored by the person or bot who wrote them.
- Legacy `junior/<email>` rows: leave them as they are, unless a
migration path is clearly correct.
- Participants: "same as today: users." Verified event authors as
participants: "not right now maybe we will change our mind later."
- "also we'd allow list usernames in juniors config for github events
(so we could allow list some bots)"
- "call it trusted authors or sometihng", then: "yes "trusted" is what
we want here, but you can use the suffix that makes sense"
- "any sender who doesnt have the allowed domain email address or is
unknown isnt trusted. bots and or other users could be listed under
trusted"
- On what trusted text may do: "trusted authors are the same as normal
authors... its just that untrusted authors we dont run"

His answers to the 14 earlier proposals: (1) "bots need to be annotated
as bots, thats important"; (2) "you can find what makes sense"; (3)
"yes"; (4) "correct"; (5) "yes but an event *is* a message so"; (6)
"yes"; (7) "sure defer to you but needs to be correct"; (8) "yep"; (9)
"yep. and users have many identities associated to them"; (10) "thats
meaningless to me, make sure its good arch and ill trust you"; (11)
"yep"; (12) "idk up to you make it correct"; (13) "sure, we dont really
have "owners" on automations anyways"; (14) "ok".

**Plan decisions David handed off (2, 7, 10, 12).** Each is a current
proposal that its step confirms: the local auth bypass gets an Identity
that cannot match a production User (step 3); the Owner repair runs only
when it is clearly correct, after a dry run (step 4b); one system
Identity with a key that no plugin or OAuth link can write (#2443); the
mock viewer Identity is in memory only (step 3).

**Target, from those answers:** one Owner per root, set at insert, human
or system, never transferred. Children read the root Owner, and child
spend rolls up to it. One system Identity; "which system" is provenance.
Web users use their sign-in Identity; the mock viewer has a mock
Identity. Bots are kind `bot` with no User. Every new user Message has
an author Identity; assistant output has none. Events are user Messages
and only set the Message author. An event author is trusted when Junior
verifies them on an allowed domain or their login is on
`trustedAuthors`; untrusted or unknown authors do not run. Event authors
are not participants. Legacy rows stay unless a migration is clearly
correct.

**Release rules:** each step ships alone and is safe under a rolling
deploy. Readers ship before writers. A column drop ships one release
after the code stops using it. No production backfill without explicit
approval, and a dry run before any repair.

**Steps:** (1) one Actor-to-Identity mapping, built in #2443 (in
review); (2) carry the Identity id; (3) real Identities and the trust
rule; (4a) write the Owner; (4b) backfill, enforce, and read the Owner
(riskiest); (5) require authors and retire stored Actors; (6) stop using
the old columns; (7) drop them. #2441 before 2, #2260 before 3, #2382
before 4a, #2181 before 5.

**Open questions for David:**
1. Mixed event batch: are untrusted entries dropped, or kept as context
that does not start a run? Plan reading: dropped.
2. Does Cursor Bugbot go on `trustedAuthors`? Plan reading: not listed
yet, so its reviews stop starting runs when step 3 ships.

**Behavior changes:** automation-run spend leaves personal spend. A
human who replies to an automation Conversation becomes a participant,
not the Owner. Child spend goes to the root Owner. Trusted author text
counts like a chat message; untrusted or unknown authors do not run. The
participant list stops showing system Identities. Locations show one row
per User.

<!-- junior-request-attribution:start -->
via **David Cramer**.
<!-- junior-request-attribution:end -->

<!-- junior-session-footer:start -->
<!-- junior-conversation-id:agent%3Af31d0b3589d3ee280ff739bacb901c33 -->

--

[View
Session](https://junior-prod.sentry.dev/conversations/agent%3Af31d0b3589d3ee280ff739bacb901c33)
[[Sentry]](https://sentry.sentry.io/explore/conversations/agent%3Af31d0b3589d3ee280ff739bacb901c33/?project=4510944073809921)

<!-- junior-session-footer:end -->

---------

Co-authored-by: sentry-junior[bot] <264270552+sentry-junior[bot]@users.noreply.github.com>
Co-authored-by: David Cramer <david@sentry.io>